iT邦幫忙

2026 iThome 鐵人賽

DAY 4
0
Claude AI

Claude Code 實戰筆記:AI coding 沒有新問題系列 第 4

# Day 4:AI 寫 Code 前不讀 Code,跟瞎猜有什麼差別

  • 分享至 

  • xImage
  •  

Code review 裡最常聽到的一句話

Code review 裡有一種 comment 出現頻率高到像罐頭訊息:「這個已經有了。」

已經有一個 date formatting util。已經有一個 error handling pattern。已經有一個 API client wrapper。但寫 code 的人沒看到,所以又寫了一個 — 行為差不多,但 API 不一樣、error handling 不一樣、edge case 處理不一樣。

Robert C. Martin 在 Clean Code 裡說:開發者花在讀 code 和寫 code 的時間比遠超過 10:1。寫 20 行之前,已經讀了 200 行。Uncle Bob 的重點是「所以 code 要好讀」,但反過來看也成立 — 一個不讀就寫的人,寫出來的東西大概率跟 codebase 格格不入。

拿 Claude Code 來說,它已經有能力搜尋 codebase、讀檔案、查 type definition。工具不缺。缺的是讀的深度。

你給 AI 一個需求,它會讀正在改的那個檔案,可能會讀 import 進來的模組。但它不會主動去找「專案裡其他地方怎麼做同樣的事」。它讀的是語法層面需要的東西,不是設計層面需要的 context — 哪些 pattern 是這個專案的慣例、哪些 util 已經存在、下游誰在用這個函式的回傳值。

先寫再說會壞成什麼樣

不讀 code 直接寫,壞法大致分三種:

Pattern 不一致。 專案裡所有資料存取都走 repository pattern,AI 在新功能裡寫了 inline query。兩邊都能動,但維護的人現在要記住兩套做法。久了之後沒人記得哪套是「正確」的,兩套都開始各自演化,最後變成兩套不相容的風格混在同一個 codebase 裡。

重造輪子。 專案已經有一個 formatCurrency() 放在 utils/ 底下,AI 在新元件裡自己又寫了一個。邏輯重複不是最大的問題 — 最大的問題是兩個版本的 edge case 處理不一樣。一個處理了 null,一個沒有。哪天碰到 null 的時候,只有其中一邊會炸。

改壞隱含假設。 AI 改了一個函式的回傳格式,不知道下游三個地方依賴它回傳 array 而不是 object。改完之後沒有 type error — 因為是 JavaScript — 直到 production 爆了。

怎麼把讀的深度拉上來

Day 3 講了「適應式規則」 — 告訴 AI 判斷的依據,而不是規定每一步。「先讀再寫」就是這個原則的一個具體應用。

在指令裡寫一條:動手前先找 codebase 裡三個類似的實作,看完再開始寫。 它不說「用 repository pattern」「用 utils/ 底下的 helper」「回傳 array 不要 object」— 那是規定式的寫法,Day 3 講過為什麼會過期。「找三個類似實作再動手」告訴 AI 的不是答案,是找到答案的方法。這也是 Claude Code 社群裡常見的 CLAUDE.md 寫法。AI 拿到這條指令之後會主動搜 codebase、找到 pattern、照著寫,一致性比沒有這條規則的時候好得多。

另一個做法是用 Claude Code 的 plan mode — 在寫 code 之前先讓它產出一份計劃 — 打算改哪些檔案、用什麼 pattern、為什麼。計劃裡如果沒有提到任何 existing implementation,代表它的讀還停在語法層面,沒到設計層面。花三秒鐘看一眼計劃,能攔掉前面三種壞法的大部分。

拆柵欄之前先問為什麼

G.K. Chesterton 1929 年在《The Thing》裡寫了一個後來很有名的比喻:

路中間有一道柵欄。改革者看了一眼說「這沒用,拆掉」。Chesterton 的回應是:在你告訴我你知道它為什麼在那裡之前,你不能拆。

AI 不讀 code 就改,就是在拆沒看過的柵欄。

那個看起來多餘的 null check,可能是因為某個 API 在特定情境下會回傳 null。那個奇怪的 setTimeout,可能是為了繞過一個 race condition。那段重複的 code 可能是刻意不抽成共用 function,因為兩邊的演化方向不同。

每個資深工程師都踩過這個坑。剛接手一個專案,覺得某段 code 寫得醜,重構完 production 就爆了,才發現那段 code 是在 work around 一個很深的 bug。

差別只是以前是人踩,現在是 AI 踩。而且 AI 踩的速度快得多 — 人類重構一段 code 可能要半天,AI 三秒就改完了。壞得也快三秒。

讓 AI 先讀再寫,就是在給它拆柵欄之前需要的 context。Chesterton 講的從來不是「不准拆」,而是「先搞懂再拆」。對 AI 來說也一樣 — 問題不是它能不能改你的 code,而是它改之前有沒有讀懂你的 code。


延伸閱讀


上一篇
# Day 3:Anthropic 砍掉 80% 的 AI 指令,效果沒變差
下一篇
# Day 5:沒有規格書的 AI 就是一台隨機打字機
系列文
Claude Code 實戰筆記:AI coding 沒有新問題9
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言